[-+|-n+] [-bacc|-nbacc] [-bad|-nbad] [-badp|-nbadp] [-bap|-nbap] [-bbb|-nbbb] [-bc|-nbc] [-br|-nbr] [-brr|-nbrr] [-bs|-nbs] [-cdb|-ncdb] [-ce|-nce] [-dj|-ndj] [-eei|-neei] [-ei|-nei] [-fc1|-nfc1] [-ip|-nip] [-ldefs|-nldefs] [-lp|-nlp] [-pcs|-npcs] [-pro|-npro] [-prs|-nprs] [-ps|-nps] [-psl|-npsl] [-sc|-nsc] [-sob|-nsob] [-st|-nst] [-tabu|-ntabu] [-troff|-ntroff] [-v|-nv]
[-c:n] [-cci:n] [-cd:n] [-ci:n] [-cli:n] [-cp:n] [-d:n] [-di:n] [-i:n] [-l:n] [-lc:n] [-tabs:n]
[-fb:...] [-fbc:...] [-fbx:...] [-fc:...] [-fk:...] [-fs:...] [-T:...]
Indent is a C program formatter. It reformats the C program in the input-file according to the switches. Switches may appear before or after the file names.
If indent is run without any files or options on the command line, indent lists the default options and a summery of usage.
Multiple source files can be specified on the command line. Wild card filenames are not supported. @ indicates that the filename that follows is the name of a file list.
The formatting is done `in-place', that is, the formatted file is written back into input-file and a backup copy of input-file is written in the current directory. If input-file is named /blah/blah/file, the backup file is named /blah/blah/file.bak.
Options begin with -, and can appear anywhere in the command. These options control how programs are formatted.
Indent defaults were set at compile time in args.c. These are overwridden successivly by profile files and the command line. The first set of changes may be set in argv[0].pro. You may set up your own `profile' of defaults to indent by creating a file called indent.pro in your login directory (pointed to by the environment variable HOME) and/or the current directory and including whatever switches you like. A `indent.pro' in the current directory takes precedence over the one in your login directory, which takes presidence over the one in the binary directory etc... If indent is run and a profile file exists, then it is read to set up the program's defaults. Switches on the command line, though, always override profile switches. The profile file switches should be separated by spaces, tabs or newlines.
University of California at Berkeley defaults are:
-nbap -nbad -nbbb -bc -br -c:33 -cd33 -cdb -ce -ci:4 -cli:0 -d:4 -di:16 -fc1 -i:4 -ip:4 -l:75 -lp -npcs -psl -sc -nsob -fca -cp:33 -nss -tabu -tabs:8
The Kernighan & Ritchie style is the one used in their influential book The C Programming Language. Kernighan & Ritchie do not put comments to the right of code in the same column at all times (nor do they use only one space to the right of the code), so Indent in this mode has arbitrarily picked column 33. The Kernighan & Ritchie style corresponds to the following set of options:
-nbad -bap -nbbb -nbc -br -c:33 -cd:33 -ncdb -ce -ci:4 -cli:0 -d:0 -di:1 -nfc1 -i:4 -ip:0 -l:75 -lp -npcs -npsl -nsc -nsob -nfca -cp:33 -nss -tabu -tabs:8
The GNU coding style is the preferred style for writing code for the GNU project. It is also the style that the GNU emacs C mode encourages. To use GNU coding standards, specify the following options:
-pcs -psl -nsc -nsob -bli:2 -ss -cp:1 -nfca -cli:0 -tabu -tabs:8
The options listed below control the formatting style imposed by indent.
if (...)
{
code
}
Specifying
-nbl
makes them look like this:
if (...) {
code
}
And specifying
-brr
makes them look like this:
if (...)
{
code
}
/*
* this is a comment
*/
Rather than like this:
/* this is a comment */This only affects block comments, not comments to the right of code.
p1 = first_procedure(second_procedure(p2, p3),
third_procedure(p4, p5));
With -lp in effect (the default) the code looks somewhat clearer:
p1 = first_procedure(second_procedure(p2, p3),
third_procedure(p4, p5));
Inserting a couple more newlines we get:
p1 = first_procedure(second_procedure(p2,
p3),
third_procedure(p4,
p5));
For example, if your program contains:
typedef unsigned long CODE_ADDR;
typedef enum red, blue, green COLOR;
you would use the options -T CODE_ADDR -T COLOR.
If the code on a line extends past the comment column, the comment starts further to the right, and the right margin may be automatically extended in extreme cases.
Indent assumes that any comment with a dash or star immediately after the start of comment (that is, `/*-' or `/**') is a comment surrounded by a box of stars. Each line of such a comment is left unchanged, except that its indentation may be adjusted to account for the change in indentation of the first line of the comment.
All other comments are treated as straight text. Indent fits as many words (separated by blanks, tabs, or newlines) on a line as possible. Blank lines break paragraphs.
If a comment is on a line with code it is started in the `comment column', which is set by the -cn command line parameter. Otherwise, the comment is started at n indentation levels less than where code is currently being placed, where n is specified by the -dn command line parameter. If the code on a line extends past the comment column, the comment starts further to the right, and the right margin may be automatically extended in extreme cases.
Indent produces and interprets some special comments. When indent cannot parse the source, it prints a message on standard error and inserts a comment into the output of the form
/**INDENT** ErrorMessage */
Indent interprets several special comments as directives. First, it makes no attempt to format lines containing the error comment described above.
Second, lines of the form:
/* INDENT OFF */
or
/* INDENT ON */
disable and re-enable indent formatting.
Any amount of whitespace may replace the spaces shown in the examples.
Third, indent allows formatting controls to be included in the source via comments of the form:
/* INDENT: arg1 arg2 arg3 ... arg4 */The arguments given are in the same syntax as the command line or profile file. For example:
/* INDENT: -cli.25 -nfc1 */
In general, indent leaves pre-processor lines alone. The only reformatting that it will do is to straighten up trailing comments. It leaves embedded comments alone. Conditional compilation #ifdef... #endif is recognised and indent attempts to correctly compensate for the syntactic peculiarities introduced.
Indent understands a substantial amount about the syntax of C, but it has a `forgiving' parser. It attempts to cope with the usual sorts of incomplete and misformed syntax. In particular, the use of macros like: #define forever for(;;) is handled properly.
Indent uses the HOME environment variable.
argv[0].pro ./indent.pro ~/indent.pro and indent.pro are profile files.
The programme has a set of default options built in. These may be overridden, successively, by:
Options in argv[0].pro (any .xxx extention is stripped first), Options in ~/indent.pro (the path ~/ is set in the environment variable HOME), Options in ./indent.pro, Options on the command line.
Indent appeared in 4.2 BSD.
Peter Hadfield, 4-04-93.
Command line option scanning rewritten. Option names cannot now start with a simplified the argument parsing routine.
Several files can be specified on the command line or a list of files can be specified. Source code cleaned up and encapsulation improved. Ported to Vanilla C, now clean compiles with all the warnings turned on.
Options -ldefs, -tabu and -tabu added. Option -bl is now -nbr for consistency. Option -cli:n now takes an integer number of spaces, rather than a float (this simplifies command line processing).
indent.pro is no longer a UNIX hidden file for DOS compatibility.
Usage and current option display added.
Added C++ support by merging the C++ compatable code found in comp.sources.misc.
Added (most of) the improvements made by Jon Saxton who ported indent to OS2.
24-05-93 Fixed a bug whare comments following a single colon ':' are indented by n-1 spaces, for example in a "case :" statment. This is masked if we are using tabs in the output.
Indent has even more switches than ls.
There might be a bug with -nbap whereby if the end of a procedure is followed by something such as the name of a type, with no intervening comment, the blank line will not be added.
It is far too large a task to fully test all possible permutations of the options, however this is not a major problem, incorrect formating is not serious. Only errors resulting in a change to the final binary file are significant, testing can therefore be simplified.
A project should be compiled and the binary saved. The source code should be (deformated and) indented. The project is then recompiled and the binaries compared. They should be identical.